High Efficiency Video Coding (HEVC) is a new coding standard that has been developed in recent years. In the High Efficiency Video Coding (HEVC) system, the fixed-size macroblock of H.264/AVC is replaced by a flexible block, named coding unit (CU). Pixels in the CU share the same coding parameters to improve coding efficiency. A CU may begin with a largest CU (LCU), which is also referred as coded tree unit (CTU) in HEVC. In addition to the concept of coding unit, the concept of prediction unit (PU) is also introduced in HEVC. Once the splitting of CU hierarchical tree is done, each leaf CU is further split into one or more prediction units (PUs) according to prediction type and PU partition.
During the current development of range extension (RExt) or screen content coding for High Efficiency Video Coding (HEVC) standard, some tools have been adopted due to their improvements in coding efficiency for screen contents. For Intra coded blocks, Intra prediction according to the conventional approach is performed using prediction based on reconstructed pixels from neighboring blocks. Intra prediction may select one Intra prediction mode from a set of Intra Modes, which include a vertical mode, horizontal mode and various angular prediction modes. For HEVC Range Extension and screen content coding, a new Intra coding mode, named Intra picture block copy (IntraBC) has been disclosed. The IntraBC technique that was originally proposed by Budagavi in AHG8. Video coding using Intra motion compensation, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 13th Meeting: Incheon, KR, 18-26 Apr. 2013, Document: JCTVC-M0350 (hereinafter JCTVC-M0350). An example according to JCTVC-M0350 is shown in FIG. 1, where a current coding unit (CU, 110) is coded using the Intra picture block copy mode. The prediction block (120) is located from the current CU and a displacement vector (112). The displacement vector is also called block vector (BV). In this example, the search area is limited to the current CTU (coding tree unit), the left CTU and the left-left CTU. The prediction block is obtained from the already reconstructed region. Then, the displacement vector and residual for the current CU are coded. It is well-known that the HEVC adopts CTU and CU block structure as basic units for coding video data. Each picture is divided into CTUs and each CTU is reclusively divided into CUs. During prediction phase, each CU may be divided into multiple blocks, named prediction units (PUs) for performing prediction process. After prediction residue is formed for each CU, the residue associated with each CU is divided into multiple blocks, named transform units (TUs) to apply transform (such as discrete cosine transform (DCT)).
In JCTVC-M0350, the IntraBC is different from the motion compensation used for Inter prediction in at least the following areas:                BVs are restricted to be 1-D for IntraBC (i.e., either horizontal or vertical) while Inter prediction uses 2-D motion estimation.        Binarization is fixed length for IntraBC while Inter prediction uses exponential-Golomb.        IntraBC introduces a new syntax element to signal whether the BV is horizontal or vertical.        
Based on JCTVC-M0350, some modifications are disclosed by Pang, et al., in Non-RCE3: Intra Motion Compensation with 2-D MVs, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Vienna, AT, 25 Jul.-2 Aug. 2013, Document: JCTVC-N0256 (hereinafter JCTVC-N0256). Firstly, the IntraBC is extended to support 2-D MVs, so that both vertical and horizontal MV components can be non-zero at the same time. This provides more flexibility to IntraBC than the original approach, where the MV is restricted to be strictly horizontal or vertical.
In JCTVC-N0256, two BV coding methods are disclosed:                Method 1—Block vector prediction. The left or above BV is selected as the BV predictor and the resulting motion vector difference (BVD) is coded. A flag is used to indicate whether the BVD is zero. When BVD is not zero, exponential-Golomb codes of the 3rd order are used to code the remaining absolute level of the BVD. Another flag is used to code the sign.        Method 2: No block vector prediction. The BV is coded using the exponential-Golomb codes that are used for BVD in HEVC.        
Another difference disclosed in JCTVC-N0256 is that the 2-D IntraBC is further combined with the pipeline friendly approach:                1. No interpolation filters are used.        2. BV search area is restricted. Two cases are disclosed:                    a. Search area is the current CTU and the left CTU or            b. Search area is the current CTU and the rightmost 4 column samples of the left CTU.                        
Among the proposed methods in JCTVC-N0256, the 2-D IntraBC, the removal of interpolation filters, and the search area constraint to the current CTU and the left CTU have been adopted in a new version of draft HEVC Rext standard.
According to JCTVC-R0309 (Pang, et al., Non-SCCE1: Combination of JCTVC-R0185 and JCTVC-R0203, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 18th Meeting: Sapporo, JP, 30 Jun.-9 Jul. 2014, Document: JCTVC-R0309 (hereinafter JCTVC-R0309)), the BV coding is modified to use the neighboring coded BVs as BV predictor (BVP). The BV predictor is derived in a way similar to the advanced motion vector prediction (AMVP) scheme in HEVC. A predictor candidate list is constructed by first checking the BV availability at spatial neighboring blocks a1 and b1 according to a priority order as shown in FIG. 2. If neither of the spatial neighbors contains block vectors, the last two coded BVs are used to fill the block vector candidate list so that the list will contain two different entries. The last two coded BVs are initialized with (−2*CU_width, 0) and (−CU_width, 0). In order to avoid the need of a line buffer to store the previously coded BVs, any of the spatial neighboring blocks a1 and bland the last BVs outside the current CTU is considered unavailable. The last two coded BVs are reset to (0, 0) for each CTU to prevent the data dependency.
Also, in HEVC, Merge candidates are derived from spatial/temporal neighboring blocks for the current block coded in an Inter coded slice. A merge_flag is used to signal whether the current block is merged into one of its candidates. If merge_flag indicates the current block use Merge mode, another index is used to signal which of the candidates is used for Merge mode. For example, if candidate block a1 in FIG. 2 is signaled as the candidate to be used, then the current block will share the same motion vector (MV) and reference picture as those of block a1.
If any of the Merge candidates is not available (e.g. not existing or non-Inter coded), one or more additional candidates are inserted. If the Merge candidate list is still not full after inserting the additional candidates, a zero-valued motion vector with reference picture index (refIdx) equal to 0 will be used to fill all the empty candidates.
Two types of additional candidates can be inserted:                1. Combined bi-predictive Merge candidate (candidate type 1),        2. Zero vector Merge/AMVP candidate (candidate type 2).        
The type-2 additional candidates are inserted after the type-1 additional candidates.
For type-1 candidates, combined bi-predictive Merge candidates are created by combining original Merge candidates. In particular, two candidates from the original candidates are used to create the bi-predictive Merge candidates. The original candidates may include mvL0 (the motion vector in list 0) with refIdxL0 (the reference picture index in list 0) or mvL1 (the motion vector in list 1) with refIdxL1 (the reference picture index in list 1). An example of the derivation process of combined bi-predictive Merge candidate is shown in FIG. 3A and FIG. 3B, where mvL0_A and mvL1_B are two uni-predictive Merge candidates. FIG. 3A illustrates an original Merge candidate list (310) and the Merge candidate list after adding combined candidate (320), where the added Merge candidates are highlighted by dotted background. Also, Merge index 0 is assigned to uni-predictive Merge candidate, mvL0_A, Merge index 1 is assigned to uni-predictive Merge candidate, mvL1_B and Merge index 2 is assigned to bi-predictive Merge candidate, (mvL0_A, mvL1_B). Candidate mvL0_A points to reference picture ref0 in reference list L0 and candidate mvL1 B points to reference picture ref0 in reference list L1 as shown in FIG. 3B. The two uni-predictive Merge candidates are combined into one bi-predictive Merge candidate as shown in FIG. 3B.
In type-2 candidates, zero-valued Merge/AMVP candidates are created by combining zero-valued and reference picture index which can be referred. FIG. 4A shows an example of adding zero-valued Merge candidates to the original Merge candidate list (410) to form a filled Merge candidate list (420). FIG. 4B shows an example of adding zero-valued AMVP candidates to original AMVP candidate lists (430) to form filled AMVP candidate lists (440). If zero-valued candidates are not duplicated, it is added to Merge/AMVP candidate set.
It is desirable to further improve the performance of IntraBC mode.